---
title: PdfAPI.Core security and authorization
summary: Authentication/authorization posture and security-relevant behaviors for this library.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-09-17
library: PdfAPI.Core
reference_type: package
---

# PdfAPI.Core security and authorization

**No authentication or authorization is implemented in PdfAPI.Core.** A targeted search for `Authorize`, `Principal`, `Identity`, `ConfigurationManager`, and `AppSettings` across the library's source returned no matches: there are no `[SaifAuthorize]` or `[Authorize]` attributes, no role checks, no claims or principal inspection, no credential handling, no encryption or hashing, and no token or secret material. This is expected, not a gap: the library is a contracts-and-utilities assembly with no request pipeline of its own. Authentication and authorization for the PDF platform are the responsibility of the hosting `PdfAPI` Web API service, which consumes this library.

## Purpose
- Document the absence of authentication/authorization enforcement points in this library.
- Record the security-relevant, consumer-facing behaviors identified in analysis so that callers (`PdfAPI`, `PdfAPI.SyncFusionCore`, `PdfAPI.Client`) can account for them at their own trust boundary.

## Security-relevant behaviors

| Concern | Finding | Source |
| --- | --- | --- |
| Unvalidated file-system paths | `Document.Load(string)`, `Document.Save(string)`, and `Document.Delete()` accept caller-supplied paths with no canonicalisation, allow-list, or traversal check, and act on them directly. A caller passing untrusted input can read from or delete an arbitrary path the process can reach. | `PdfAPI.Core\Document.cs` |
| Destructive dispose | `Document.Dispose()` deletes the backing file, and `DocumentRange.Dispose()` / `PdfResult.Dispose()` cascade into it ([BR-24](business-rules.md#br-24-disposing-a-document-deletes-its-file)). A `using` block over a caller-owned source file destroys that file. | `PdfAPI.Core\Document.cs`, `PdfAPI.Core\Extract\DocumentRange.cs`, `PdfAPI.Core\PdfResult.cs` |
| Delete-before-validate | `ValidatePdf(Document, PdfOptions)` deletes the input file before checking that the content is a valid PDF ([BR-07](business-rules.md#br-07-input-file-cleanup-after-load)), so rejected input is already gone from disk. | `PdfAPI.Core\Services\PdfClientService.cs` |
| Silent failure | `Document.Delete()` catches and discards all exceptions, returning `false` with no diagnostic ([BR-23](business-rules.md#br-23-document-deletion-never-throws)). | `PdfAPI.Core\Document.cs` |
| Untrusted document parsing | `PdfReader`, `PdfStamper`, and `PdfCopy` from iTextSharp 5.5.11 (released 2016) are invoked directly on caller-supplied bytes. Parsing untrusted PDFs on a long-unpatched third-party parser carries the usual malformed-document risk; no version-specific advisory was checked as part of the underlying analysis.** | `PdfAPI.Core\Services\PdfClientService.cs`, `PdfAPI.Core\packages.config` |
| Unbounded in-memory decoding | `IsPdf`, `Version`, and `GetPageCount` decode the entire byte array into a string before inspecting only the first few bytes or running a regex, roughly doubling peak memory per call and exposing large-document denial-of-service pressure.* | `PdfAPI.Core\Services\PdfClientService.cs` |
| Environment literal in source | `PdfAPI.Core.v1.DocumentRangeFactory.CreateById` embeds the UNC path `\\saif\share\is\pdf\qa\input` as a default parameter value. Not compiled into the assembly, but shipped as source in the packaged NuGet packages. | `PdfAPI.Core\v1\DocumentRangeFactory.cs` |

No secrets, credentials, connection strings, or API keys were found anywhere in this library's source.

## Constraints and usage notes
- Consumers that accept file paths or PDF bytes from an external or untrusted caller must apply their own path canonicalisation, allow-listing, and content validation before delegating to `Document` or `PdfClientService`; this library performs none of that validation itself.
- Do not wrap a caller-owned source file's `Document` in a `using` block, and do not call `Document.Dispose()`/`PdfResult.Dispose()` on a result whose backing file must be retained, since disposal unconditionally deletes it.
- Treat a `false` return from `Document.Delete()` as inconclusive rather than diagnostic, since the underlying exception is discarded.

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts. Statements marked with `**` could not be confirmed; treat
> as unknown until verified.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Architecture](architecture.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Business rules](business-rules.md)
- [API reference](api/index.md)

## Sources
- `PdfAPI.Core\Document.cs`
- `PdfAPI.Core\Extract\DocumentRange.cs`
- `PdfAPI.Core\PdfResult.cs`
- `PdfAPI.Core\Services\PdfClientService.cs`
- `PdfAPI.Core\packages.config`
- `PdfAPI.Core\v1\DocumentRangeFactory.cs`